< back

Tindahan POS: A Cloud-Synced Retail Engine Built for Local Sari-Sari Stores

Standard retail software is built for structured grocery chains with centralized cashier lanes and barcode standards. But what happens when you need software for a Philippine neighborhood sari-sari store? A place where customers buy single pieces out of a sealed pack, take sodas in glass bottles that require deposit tracking, and occasionally buy items on informal credit.

Most POS apps force these informal store owners to conform to rigid corporate workflows, causing them to eventually abandon the software and revert to pen and paper. I wanted to solve this.

Here is how I designed and built Tindahan POS (TPOS)—a lightweight, cloud-synced retail engine that actually respects and automates the informal workflows of local micro-retailers.

Step 1: The Zero-Hardware Architecture

Small store owners operate on paper-thin margins. Telling them to buy a ₱15,000 Android tablet and Bluetooth receipt printer just to run software is an immediate dealbreaker.

I architected TPOS as a Progressive Web Application (PWA) using React, Vite, and Tailwind CSS. Instead of requiring proprietary hardware, the system turns any cheap Android smartphone or old laptop into a fully functional register. For barcode scanning, I integrated a native browser BarcodeDetector polyfill that accesses the phone's back camera, running a continuous detection loop with a 2-second anti-double-scan cooldown. No hardware investment required.

Step 2: Automating Neighborhood Workflows

A sari-sari store operates on highly specific cultural workflows. I built custom algorithms to handle these edge cases natively:

1. The Pack-to-Piece (Tingi) Converter: When a customer asks to buy a single diaper from a pack of 30, the store owner presses "✂️ I-tingi." The app immediately deducts one wholesale pack from inventory, divides the capital cost by 30, suggests a retail markup per piece, and pins the remaining 29 pieces to a quick-access drawer.

2. Smart Price-Protection (FIFO/FEFO): When wholesale prices rise, store owners often lose money selling old stock at outdated prices. My engine automatically tracks stock batches using First-In, First-Out and First-Expired, First-Out logic, dynamically bumping the active selling price to match the highest current batch cost to prevent capital erosion.

3. Proportional Credit (Utang): Customers rarely pay their debts in full. When someone makes a partial payment (hulog), the system proportionally splits the payment across capital cost, retail profit, and service revenue to keep the merchant's financial dashboard 100% accurate.

Step 3: Serverless Cloud Syncing

To keep the platform completely free for the merchant during the MVP phase, I bypassed expensive backend hosting and built a serverless middleware using Google Apps Script (GAS).

When a transaction occurs on the React frontend, it updates a local localStorage queue immediately for a snappy user experience, then asynchronously fires a JSON payload to a Google Apps Script endpoint. To prevent data collisions when two family members use the app simultaneously on different phones, I implemented LockService in the backend to serialize concurrent requests, ensuring inventory arrays merge cleanly in the cloud before updating the master Google Sheet database.

The Result

TPOS successfully handles the messy, complex reality of neighborhood retail. The dashboard aggregates real-time sales and capital recovery metrics across all connected devices, filtering them dynamically by day, week, month, or year.

Building this project was a masterclass in pragmatic software design: proving that the best retail software isn't necessarily the one with the most enterprise features, but the one that adapts seamlessly to the user's actual environment.